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(57) A method and apparatus for secure and scala- 
ble key management in a multicast network environ- 
ment is provided. In a first portion, one or more seed 
nodes on the network receive a multicast transmission 
request for a cryptographic key from a requesting node. 
The seed node compares the identity of the requesting 
node with an authenticated predetennined list of nodes 
having permission to receive the cryptographic key If 
the comparison indicates the requesting node is not a 
member of the authenticated predetermined list, the 
seed node denies the multicast request However, if the 
comparison Indicates that the requesting node Is a 
member of the predetermined list of nodes, the crypto- 
graphic key is transmitted using a secure unicast key 
distribution technique such as SKIP. A second portion 
concerns the requesting node which generates a multi- 
cast request to obtain the cryptographic key from one 



or more seed nodes and one or more keyed nodes on 
the internetwork The multicast request for the crypto- 
graphic key is initially transmitted a minimum hop count 
over the internetwork to locate the closest seed node. 
The requesting node delays a brief time period waiting 
for at least one response from at least one seed node 
or keyed node on the internetwork. If the at least one 
response Is not received within this time perkxl, the min- 
imum hop count is increased by a hop count increment 
and the requesting node repeats the above steps. Even- 
tually, the requesting node increases the hop count and 
receives the cryptographic key over a secure unicast 
key management technique such as SKIP As a final 
step, the requesting node is convered Into a keyed node. 
The keyed node acts as a seed node and provides the 
cryptographic key to other requesting nodes on the in- 
temetwork. 
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Description 

Field of the Invention 

The present invention relates generally to computer 
cryptography and, more specifically, to a method and 
system for secure distribution of cryptographic keys on 
multicast networks. 

Background Of The Invention 

Network computing has grown at a phenomenal 
rate over the last decade. In a network computing envi* 
ronment, a user has access to the computing power of 
multiple computers located on a network. Sun Microsys- 
tenr^ Inc., a leader in network computing, even devised 
a marketing campaign around the slogan "The Network 
!s the Computer"™ to emphasize the commercial suc- 
cess of this growing segment of the computing market^ 
Recently, this slogan has become reality as millions of 
users have tapped the computing resources available 
from the thousands of computers available on the Inter- 
net and the World Wide Web. 

One of the more interesting areas of research in net- 
work computing concerns how to simultaneously and ef- 
ficiently transmit infomnation to multiple nodes on a net- 
work. In particular, many people are researching multi- 
cast protocols. A multicast protocol allows a transmitter 
node on a network to send the same data packets to 
multiple specific receiver nodes on a network without us- 
ing separate point-to-point connections. The point-to- 
point connections, also referred to as unbast connec- 
tbns, are not desireable because each point-to-point 
connection establishes a seperate logical network con- 
nection between the transmitter node and each receiver 
node on the network. The seperate logical network con- 
nection requires seperate network resources, such as 
a seperate IP (Internet Protocol) connection, to estab- 
lish the actual connection as well as additional band- 
wkfth to transmit multiple copies of the same packet. 
This wastes network resources because the information 
being transmitted over each network connection is iden- 
tical. 

The multicast protocol enables the transmitting 
node to transmit a series of data packets to multiple re- 
ceivers without establishing a seperate network connec- 
tion for each receiver node or sending duplicate packets 
of the data over a network. Instead, the multicast proto- 
col sends a single stream of packets over the network 
in which only members of the multicast group are able 
to read. Multicast is an improvement over unicast pro- 

1 . The Network^ the Computer, Sun,, the Sun logo, Sun Microsysteme. 
Solaris. Ultra and Java are trademarke or registered trademarte of Sun 
Microsystems, Inc. In the United States and in other countries. All 
SPARC trademarics are used under license and are trademarte or reg- 
istered trademarics of SPARC International, Inc. In the United States and 
other countries. Products t>earing SPARC trademario are based upon 
an architecture developed by Sun Microsystems. Ino. UNIX Is a regis- 
tered trademarte In the United States and other countries exclusively li- 
censed through XAOpen Company, Ltd. 



tocols using numerous polnt-to-point channels because 
multicast does not send redundant packets of informa- 
tion. Multicast is also advantageous because only a pre- 
determined list of multicast members can receive the 
s multicast transmission. 

An increasing number of practical applications 
available on the Internet such as live stock quotes, video 
conferencing, white board applications, electronic com- 
merce, remote learning, and other group communica- 
te tions are migrating to multicast protocols to resolve 
these network bandwidth deficiencies. These applica- 
tions will invariably contain sensitive and confidential In- 
formation about their users. Consequently, packets 
transmitted over these multicast networks should be en- 
crypted to prevent eavesdropping by Individuals not in 
the multicast group. 

Accordingly, there are at least two general concerns 
in designing robust cryptographic systems for encrypt- 
ing infonnation distributed on a multicast network: en- 

20 cryption and key management. First, the enciyptton 
technique used to encrypt the information must not be 
easily compromised by an unauthorized eavesdropper 
To evade such eavesdroppers, algorithms such as Data 
Encryption Standard (DES) are used to to encrypt data 

25 using a cryptographic key. The protection against hack- 
ers and Interlopers lies in the length of the cryptographic 
key in addition to the complexity of the encryption algo- 
rithm. Generally, a longer cryptographic key requires 
more computer resources and more time to decrypt. 

30 Thus, by changing the cryptographic keys at regular 
time intervals, hackers will not have sufficient time to 
compute the cryptographic keys. 

The second, and often more difficult, aspect of cryp- 
tographic systems lies in the key management. Key 

35 management typically involves secure key distribution 
and scalability. Essentially, key distribution must be se- 
cure or a hacker will obtain the key and security will be 
compromised. Moreover, in a large multk^st network 
the key distribution must scale well so that a large 

40 number of users can obtain the keys quickly and effi- 
ciently. The size of the multicast group and request for 
keys should not degrade performance of the crypto- 
graphic system. Establishing management techniques 
which scale well for large multicast groups has remained 

4S a problem in cryptographic systems. 

Typically, modern cryptographic systems use key 
management to manage distribution of a traffic key and 
a key encrypting key. The traffic key is a key used to 
actually encrypt the data being transmitted across a net- 

so work while the key encrypting key is a key used to en- 
crypt the traffic key and prevent it from being discovered 
enroute to a receiving node. Both of these keys must be 
distributed In a manner which scales to multk;ast net- 
works with a large number of multicast members. 

ss Unfortunately, existing key management tech- 
niques often use a single sen/er, sometimes referred to 
as a Group Coordinator or GC. to distribute the traffk; 
keys or key encrypting keys associated with a multicast 



2 



EP0 887 982 A2 



transmission. The GC maintains secure key distribution 
but can be overwhelmed if the requests are too frequent 
and too numerous. Insomecases, requesting nodes ge- 
ographically distant from the single server will experi- 
ence delays in receiving a key and can miss part, if not 
all. of a multicast transmission in the interim. In a worst 
case, a large multicast group can suddenly overload the 
GC with requests such that certain members of the mul- 
ticast group never receive any keys. Members of the 
multicast group without the approplate keys would be 
excluded from the multicast transmission entirely. Key 
management techniques must be improved to scale 
with large multicast groups. 

A multicast extension using the SKIP ^ (Simple Key 
Management for Internet Protocols) protocol scales well 
for distributing the traffic key but does not scale as well 
for distributing the key encrypting key. In multicast SKIP, 
the traffic key Is used to encrypt data in a packet The 
traffic key is an Inline traffic key because it is Included 
with each packet. To keep the traffic key confidential. 
SKIP for multicast IP (Internet Protocol) encrypts the 
traffic key using a key encrypting key referred to as a 
Group Interchange Key or GIK. 

Distribution of the traffic key In multicast SKIP 
scales well to large multicast groups because each 
member of the multicast group receiving a packet has 
a copy of the traffic key. However, the distribution of the 
GIK does not scale as easily. Unlike the inline traffic key, 
SKIP uses public-key key distribution to distribute the 
GIK with a single sen/er known as the Group Controller 
or GC. When menr^bershlp in the multicast group gets 
too large and geographically spread out, the GC can 
have difficulty distributingthd GIK. Thus, white traffk: key 
distribution using an Inline traffic key is highly scalable, 
the distribution of the GIK from a single GC remains only 
moderately scalable. Details on multicast SKIP are in- 
cluded in the paper entitled 'Design and implementation 
of SKIP", authored by Ashar Aziz and Martin Patterson, 
June 28. 1995. 

Other existing key-management techniques which 
have not addressed scalable key distribution techniques 
also suffer problems similar to the ones discussed 
above. One technk^ue called Group Key Management 
Protocol (GKMPi) contemplates that the GIK (referred 
to in GKMP as a "traffic key") can be distributed by in- 
dividual members of a multicast group but does not in- 
dicate an efficient and secure technique for selecting 
members of the muRicast group to distribute the key en- 
crypting key. Further, GKMP does not discuss a secure 
means in whteh key requests for the GIK are fulfilled. 
Essentially, the GKMP technique can still overioad a 
group owner or group coordinator with key requests be- 
cause the load associated with fulfilling these key re- 
quests is not necessarily distributed evenly over multiple 

1 .Sotetice(TM) PC'SKIP(TM) SunSoreeR(TM) SKIP are trademarks of 
Sun MicroGysteme, Inc. 

1.IETF Intemet-OrafI Group Key Management Protocol Architecture. 
Hugh Harney and Carf Muckenhlm. SPARTA. Inc. June 18. 1996 



sen/ers. 

Another technique discussed in RFC 1 949 address- 
es multicast key distribution In the context of a specific 
multicast routing protocol using Core Based Trees 
5 (CBT). This scheme has the drawback of tying the key 
distribution to a specific multicast routing protocol, 
namely CBT Moreover, it also suffers from the problem 
of having to involve and trust entitles whose role is de- 
termined by virtue of the multicast routing protocol. Un- 
to fortunately, the CBT multicast routing protocol deter- 
mines the efficiency of transmitting multicast data based 
on a partkjular route and not based on which nodes on 
the networic are to be trusted as a secure node for dis- 
tributing a key. 

IS What is needed is a technique for managing keys 
on a secure network which scales based on the load 
and geographic tocatbn of a rap'Kily growing multicast 
group. This technique should not compromise the level 
of security during transmission or reduce either fonvard 

20 or reverse secrecy. 

Summary Of The Invention 

Embodiments of the present inventbn provide a 

2S method and apparatus for secure and scalable key man- 
agement in a multteast network environment. One em- 
bodiment of the present Invention securely distributes a 
multicast cryptographic key, Initially located on one or 
more seed nodes, to a requesting node. In one multicast 

30 environment the multicast cryptographic key is a key en- 
crypting key called a group interchange key (GIK) and 
is used to encrypt a multicast traffic key. Accordingly, 
the seed nodes in this one embodiment are one or nrK>re 
nodes on the network which Initially hold the GIK and 

35 are capable of securely distributing the GIK in accord- 
ance with principles of the present Inventbn. Generally, 
seed nodes are distributed In the network so they are 
geographically close to the concentration of requesting 
nodes in the network. 

^0 Initially, one or more seed nodes on the network re- 
ceives a multicast transmission request for the multicast 
ciyptographic key from a requesting node. The multicast 
request Is neither encrypted nor authenticated and 
therefore is insecure. Typically, the seed node closest 

45 to the requesting node receives the request first and re- 
sponds. The closest seed node determines if the re- 
questing node making the multicast request has permis- 
sbn to receive the multicast cryptographic key by per- 
forming several steps. First, the seed node compares 

so the identity of the requesting node with an authenticated 
list of nodes having permission to receive the multicast 
cryptographic key. If the comparison indicates the re- 
questing node is not a member of the authenticated pre- 
determined list of nodes having permission to receive 

55 the multicast cryptographic key, the seed node denies 
the multicast request. However, if the comparing step 
indbates the requesting node is a member of the pre- 
determined list of nodes having permission to receive 
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the multicast cryptographic key, the multicast crypto- 
graphic kQy is transmitted using a secure unicast Icey 
distribution technique such as unicast SKIP. 

Unlike existing key management techniques, a re- 
questing node can request a multicast cryptographic s 
key from a number of different seed nodes on the net- 
work. This technique off loads the processing from a sin- 
gle seed node or group controlber (GC) because any 
one of the seed nodes on the network can distribute the 
multicast cryptographic key. 10 

This technique is also advantageous because an 
insecure multicast request requires less processing on 
the part of the seed node than a secure multicast re- 
quest which is encrypted and authenticated. Despite us- 
ing an insecure request, a multicast key distribution i5 
technique implemented in accordance with principles of 
the present invention remains secure because the seed 
node distributes a multicast cyptographic key using a 
secure unicast key management technique such as uni- 
cast SKIP. 20 

A second embodiment of the present inventfon ex- 
ecuted on the requesting node enables the requesting 
node to obtain a multicast cryptographic key from the 
seed node closest to the requesting node on the inter- 
network using an expanding ring of requests. Further, 25 
once the requesting node receives the multicast cryto- 
graphic key, the second embodiment converts the re- 
questing node Into a keyed node which can then distrib- 
ute the multicast cryptographic key to subsequent re- 
questing nodes in the multicast group. Unlike the seed 30 
node, the keyed node initially does not have a copy of 
the multicast cryptographic key and can not distribute 
the multicast cryptographic key until the requesting 
node's request for the multuast cryptographic key Is 
successfully filled. 35 

In accordance with the second embodiment, the re- 
questing node generates a multicast request to obtain 
the multrcast cryptographic key from one or more seed 
nodes and one or more keyed nodes on the intemet- 
work. The multicast request for the multicast crypto- 40 
graphic key is initially transmitted a minimum hop count 
over the internetwork to locate the closest seed node. 
The hop count provides an upper limit on the number of 
networks the request will traverse to locate a seed node. 
The requesting node delays a brief time perkxJ waiting 45 
for at least one response from at least one seed node 
or keyed node on the internetwork. If the at least one 
response is not received within this time period, the min- 
imum hop count is increased by a hop count increment 
and the requesting node repeats the requesting process so 
above. By increasing the hop count over time, an ex- 
panding ring of multicast key requests increases the 
likelihood of locating a seed node with the multicast 
cryptographic key while minimizing the amount of net- 
work traffic. Eventually, tiie requesting node Increases 55 
the hop count and receives the multicast cryptographic 
key using a secure unicast key management technique 
such as unk:ast SKIP As a final step, the requesting 



node is converted into a keyed node which provides the 
multicast cryptographic key to other requesting nodes 
on the Intemetwork. 

Embodiments of the inventbn offer several advan- 
tages in the area of key management for use in encryp- 
tion systems which were previously unavailable In the 
art. Unlike existing techniques, this key management 
system scales well in a large multicasting networks with 
members spread out over a large geographic distance. 
In the past, a single group coordinator (GC) would be- 
come quickly ovenwhelmed If all the members in a mul- 
ticast group requested an encryptksn key In a short time 
interval. For example, the multicast SKIP protocol used 
a single GC to distribute the multicast cryptographic key, 
called the group interchange key (GIK), to each member 
of the multicast group who wanted to receive multicast 
transmissions. This worked well for small multicast 
groups but dkJ not scale well for larger multicast groups. 
By enhanching SKIP with teachings of the present in- 
vention, the processing associated with distributing the 
key Is spread out to multiple seed nodes and keyed 
nodes on the internetwork. This technique minimizes 
the demand on a central GC because members of the 
multicast group can request a GIK from the nearest 
keyed node or seed node rather than one centrally lo- 
cated GC. The expanding ring of multicast requests fur- 
ther exptoits the availability of cryptographic keys on 
multiple seed nodes and keyed nodes on a networic by 
making requests for the multicast cryptographic key 
from the closest seed nodes and keyed nodes. 

The techniques used by the present Invention are 
also beneficial because they balance the processing 
toad associated witii key distribution based on the geo- 
graphic kxjation of key requests. Each additional cryp- 
tographic key request establishes a keyed node which 
can distribute the cryptographic key to other nearby 
nodes on the Intemetworie Using multiple seed nodes 
and keyed nodes to distribute the multicast cryptograph- 
ic key distributes the processing toad to many different 
nodes rather than one group controlloer or GC. 

Furtiier, requesting a cryptographic key using an 
expanding ring tocates nearby seed nodes or keyed 
nodes rather tiian a distant node on the network. This 
minimizes network traffic and makes key distribution 
fast and efficient. Consequently, members in a large 
multicast group will experience consistent key distribu- 
tion perfonmance when requesting cryptographic keys 
even If they are tocated In different geographic locations. 



Brief Description Of The Drawings 

Embodiments of the present Invention are Illustrat- 
ed by way of example, and not by way of limitation, in 
the figures of the accompanying drawings and in whtoh 
like reference numerals refer to similar elements and in 
whtoh: 
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RG. 1 illustrates a computer network for practicing 
one key-management technique for cryptogrpahic 
systems in accordance with the present invention. 
FIG. 2 is a flow chart Indicating the overall steps 
used in accordance with one embodiment of the 
present Invention to distribute a multicast crypto- 
graphic key to a requesting node from either a seed 
node or a keyed node ; 

RQ. 3 is a flow chart outlining the overall steps used 
by one embodiment of the present invention to ob- 
tain a multicast cryptographic key; and 
RQ. 4 illustrates one embodiment of an encrypted 
unicast packet generated for securely transmitting 
aGIK. 

Detailed Description 

Environment/Preconditions 

FIG. 1 Illustrates a computer network 100 for prac- 
ticing a key-management technique for cryptographic 
systems In accordance with the present invention. Gen- 
erally, embodiments of the present lnventk>n are de- 
signed to be implemented in an intemetwork which re- 
quire a key-management technique for the securely dis- 
tributing cryptographic keys for multicast transmissfons. 
As will be apparent from the discussion below, embod- 
iments of the present Invention exhibit excepttonal scal- 
ability in large key-management scenarios by strategi- 
cally distributing the associated processing load. For ex- 
ample, this key-management technique is particularly 
useful in secure multicast transmissions where the ciyp- 
tographk: key must be distributed to a large iriultteast 
group having members spread out over a large geo- 
graphic area. 

Referring to FIG. 1 , computer network 1 00 includes 
sen/er computers 102 and 104 configured to communi- 
cate with a client computer 106 over a network 110. 

Sewer 1 02 includes a network Interface 1 1 2, a proc- 
essor 114, a primary storage 116, a secondary storage 
118, and an I/O (input output) interface 120 which facil- 
itates communication between these aforementioned 
elements. Network interface 112 couples server 102 to 
network 110 and facilitates two-way data communica- 
tion between server computer 102 and other computers 
on the network 110. For example, if network interface 
1 1 2 is an integrated services digital network (ISDN) card 
or a modem, network interface 112 provides a physical 
connection to the corresponding type of telephone line. 
If network Interface 112 Is a local area network card 
(LAN) card, network interface 112 provides a physical 
connection to a compatible LAN. Wireless links are also 
possible. Preferably, the client and sewer computers 
coupled to this network transmit Information utilizing the 
TCP/IP protocol. Other network protocols such as SNA, 
X.25, Novell Netware^ Vines, or /VppleTalk could also 

1 . Netwam is a registered trademark of NoveD. Ino. In the Ufttted States 
and other oountiles. 



be used to provWe similar client-sen/er communication 
capabilities. In any such Implementation, network inter- 
face 1 1 2 sends and receives electrical, electronnagnetic, 
or optical signals which carry digital data streams rep- 

5 resenting various types of information. 

Network 1 1 0 typically provides data communication 
through one or more networks to other data devices. For 
example, network 110can provkJe a network connection 
between server 1 02 and client 1 06, in part, using a world 

10 wide packet data communication network now com- 
monly referred to as the "Internet*. The Internet uses 
electrical, electronnagnetic, or optical signals to carry 
digital data streams representing various types of Infor- 
nnatton. The signals carried through network 110 and 

'5 through network interface 112, which carry the digital 
data to and from server 1 02, are exemplary fomis of car- 
rier waves transporting the information. 

Sender 102 can send messages and receive data, 
including program code, through network 110, and net- 

20 work line 1 1 2, In the Internet example, a sewer compu- 
ter 104 might transmit a requested code for an applica- 
tion program through the Intemet using network 110 to 
server computer 102. In accord with the Inventfon, one 
such downloaded application is Method and System for 

25 SEcure Distribution of Cryptographic Keys on Multicast 
Networks and described herein. The received code can 
be executed by server computer 102 as it is received, 
and/or stored in a storage device for later executkjn. In 
this manner, server computer 1 02 can obtain application 

30 code in the form of a carrier wave. 

Typically, processor 1 1 4 on sender 1 02 fetches com- 
puter instructbns from primary storage 116 through I/O 
interface 120. After retrieving these instructions, proc- 
essor 1 1 4 executes these the computer Instructions. Ex- 

55 ecuting these computer instructions enables the proc- 
essor 1 14 to retrieve data or write data to primary stor- 
age 116, secondary storage 118, display information on 
one or more computer display devices (not shown), re- 
ceive command signals from one or more Input devices 

^ (not shown), or retrieve data or write data to other com- 
puter systems coupled to networit 110 such as server 
104. and client 106. Those skilled in the art also under- 
stand that primary storage 116 and secondary storage 
1 1 8 can include any type of computer storage including, 

45 without limitation, randomly accessible memory (RAM), 
read-only-memory (ROM), magnetic storage devices 
and optical storage media such as CD-ROM. In one em- 
bodinrtent, processor 114 can be any of the S PARC 
compatible processors, UltraSPARC compatible proc- 

50 essors or JAVA^ compatible processors available from 
Sun Microsystems, Inc. of Mountain View, California. Al- 

1 .JAVA, PicoJAVA. UftraJAVA, HoUAVA, The Network to the Computer. 
Sun, the Sun logo. Sun Microsystems, Solaris, and Ultra are trademarks 
or registered trademarks of Sun Microsystems, Inc. in the United States 
and in other countries. All SPARC trademarks are used under license 
55 and are trademarics or registered trademari(8 of SPARC International, 
Ino. in the United States and other countries. Products bearing SPARC 
trademariCB are based upon an architecture developed by Sun Micro- 
systems, Inc. UNIX Is a registered trademark in the United States and 
other oountiies exdush/ely fleensed through XJOpen Company. Ltd. 
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ternatively, processor 114 can be based on the Power- 
PC processor available from Motorola of Schaumburg, 
Illinois, or any of the Pentium or x86 compatible proces- 
sors available from the Intel Corporation or other corpo- 
rations such as AMD, and Cyrix. s 

Primary storage 116 includes an operating system 
122 for managing computer resources. Preferably, this 
operating system is the Solaris operating system or any 
operating system with support for object oriented pro- 
gramming languages such as the JAVA programming io 
language or high level programming languages such as 
C. Also Included in primary storage 116 is a key distri- 
bution process 124 designed in accordance with the 
present invention and a key request process 126 also 
designed in accordance with the present invention. Em- is 
bodiments of key distribution process 124 concern the 
secure distributbn of a multicast cryptographic key from 
one or more seed nodes or one or more keyed nodes 
to one or more requesting nodes. Generally, the re- 
questing nodes are coupled to different networks on an so 
internetwork and are requesting the multicast crypto- 
graphic key to participate in a multrcast transmission. In 
another embodiment of the present invention, key re- 
quest process 126 generally concerns how the one or 
more requesting nodes request the multicast crypto- 2S 
graphic key from the one or more seed nodes and the 
one or more keyed nodes. Accordingly, key distribution 
process 1 24 and key request process 1 26 work together 
In a client-server relationship as discussed In further de- 
tail below. This client-server relationship reduces traffic 30 
and distributes the load associated with key manage- 
ment in a large multicast group. Those skilled in the art 
will understand that the multk^ast cryptographic key can 
be used as traffic keys, which encrypts multicast data 
directly, or as a key encrypting key used to encrypt traffic 55 
keys rather than the actual data 

In one aspect of the present invention, key distribu- 
tion process 124 provkJes an improved method and ap- 
paratus for distributing a multicast cryptographic key to 
a requesting node from either a "seed" node or a "keyed" 40 
node. In this context, the requesting node Is a node on 
the network which needs the multicast cryptographic 
key to decrypt data packets being transmitted over the 
network. The "seed" node Includes any node on the net- 
wori< Initially "seeded" with the multicast cryptographic 4s 
key being requested. In contrast to the "seed" node, the 
"keyed" nodes are those nodes which receive the mul- 
ticast cryptograph^ key only after requesting the multi- 
cast cryptographic key vis a vis embodiments of the 
present invention. The seed node or keyed closest to so 
the requesting node on the network provides the multi- 
cast cryptographic key to the requesting node. Details 
on seed nodes and keyed nodes are discussed In further 
detail bebw. 

Referring to FIG. 2, a flow chart indicates the overall ss 
steps used by one embodiment of the present invention 
to distribute a multicast cryptographic key from either a 
seed node or a keyed node to a requesting node . Ini- 



tially, step 202 establishes the seed nodes on the net- 
work when a multteast group Is created. Seed nodes in- 
itially receive the multicast cryptographic key before the 
other members of the multbast group. Typically one 
seed node is used if the size of the multicast group is 
small and restricted to a small geographic area. Multiple 
seed nodes are generally used if the multicast group Is 
large and spread out over a large geographic area. For 
example, if the group membership spans a wkJe geog- 
raphy, multiple seed members are strategically placed 
close to large subsets of the multicast group members. 
Consequently, a multicast group including members in 
eastern Europe and the western United States would 
have multiple seed members placed in various locatbns 
in eastern Europe and the western United States to im- 
prove the key distribution process. 

At step 204 one of the seed nodes established in 
step 202 receives a multicast transmission for a multi- 
cast cryptographic key from a requesting node. Typical- 
ly, the multicast request is made using an insecure 
transmission technique over a well known port on the 
networic. The insecure multicast request Is generally 
processed move quickly and efficiently than a secure 
request because the insecure request is neither authen- 
ticated nor encrypted. As will be apparent from the dis- 
cussion below, using Insecure request at this stage does 
not compromise the security of the overall key distribu- 
tion technique. 

Next, processing transfers from step 204 to deter- 
mination step 206 where the seed node determines if 
the requesting node has permission to receive the mul- 
ticast cryptograph^ key. The purpose of this step is to 
limit the access to multicast transmission to only the 
members of the multicast group. Initially, the seed node 
compares the requesting node's Identity with an authen- 
ticated predetermined list of nodes having permlssbn 
to receive the requested multicast cryptographic key If 
the comparison indicates the requesting node is not 
member of multicast group, processing transfers from 
step 206 to step 208 where the seed node denies the 
multicast request. However, if the comparison indicates 
that the requesting node is a member of the predeter- 
mined list of nodes, processing will transfer from step 
206 to step 210 where the seed node responds to the 
multicast request for the multicast cryptographic key. In 
one embodiment, the authenticated predetermined list 
of nodes is an access control list or ACL Typically, the 
ACL Is authenticated using a digital signature and dis- 
tributed to each member of the multicast group prior to 
the multicast transmission using techniques well known 
to those skilled in the art. The ACL includes alt the nodes 
approved for inclusion in the secure multicast transmis- 
sion. 

Assuming the requesting node is on the authenti- 
cated predetermined list of nodes, processing transfers 
from step 206 to step 210 where the seed node transfers 
the multicast cryptographs key over the network to the 
requesting node using a secure unlcast key manage- 
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ment technique such as unicast SKIP. Unicast SKIP us- 
es public key key-distribution techniques. Public key 
key-distribution is advantageous because keys can be 
distributed quickly, efficiently, and securely over an in- 
ternetwork. For example, a seed node using unicast 
SKIP has a private key /and a certified publrc key g^ mod 
p. Similarly, the particular requesting node has a private 
key /and acertified publk: key gimod p. Both of the public 
keys are available to the public from a certified distrib- 
utor in the f onn of a public key certificate. The seed node 
and requesting node pair can then calculate a mutually 
shared secret g^ mod p using the well known Diffie-Heli- 
man algorithm. Specifically, the seed node and the re- 
questing node calculate the shared secret based on 
knowledge of the other's identify and the corresponding 
public key certificate. Consequently, the actual shared 
secret does not need to be explicitly communicated to 
either the seed node or the requesting node over the 
Internetwork. 

The mutually shared secret g^i mod p is used to de- 
rive a first cryptographic key, which Is denoted K||. Ini- 
tially, the seed node derives this first cryptographic key 
by taking the low-order bits of gfl mod p corresponding 
to the predetermined bit size of the third key. The seed 
nodes computes and uses the first key Kjj as a master 
or key-encrypting key to encrypt a second cryptographic 
key. The second cryptographic key is a key-encrypting 
key and Is used to encrypt the multicast encryptbn key. 
The multicast enciyption key is the group interchange 
key or GIK used to encrypt multicast data transmitted 
over the network. The seed node sends the requesting 
node an encrypted unicast packet generated using the 
two step encryptk^n procedure discussed above. FIG. 4 
illustrates one embodiment of an encrypted unicast 
packet generated for securely transmitting a GIK. In 
SKIP, the second cryptographic key and the multicast 
cryptographs key are distlrbuted in the packet transmit- 
ted over the internetwork between the seed node and 
the requesting node. Unicast packet illustrated in FIG. 
4 includes a second cryptographic key 404 encrypted 
using a first key Ky 402 derived using a public key, a 
multicast cryptographs key or group interchange key 
406 encrypted using second cryptographs key 404, and 
a clear header 408 utilized to route the unsast packet 
over the Internetwork. 

The requesting node receives the unicast packet 
and computes the first cryptographkJ key Ky in a similar 
manner to the seed node and decrypts the second cryp- 
tographic key. The requesting node then uses the sec- 
ond cryptographic key to decrypt the data packet and 
isolate the multicast cryptographic key for use later in 
the multicast transmission. It should be understood if an 
imposter poses as the requesting node, the second key 
and the multicast cryptographic key remain secure. The 
imposter requesting node can obtain the unicast data 
packet but will not have the correct private key associ- 
ated with the true requesting node. This will prevent the 
imposter node from computing the shared secret value. 



deriving the first cryptographic key, decrypting the sec- 
ond cryptographic key, and consequently obtaining the 
multicast cryptographic key. Details on the use of secure 
unicast SKIP are included in U.S. Patent Serial Number 
5 5,548,646 entitled "System for Signatureless Transmis- 
sion and Reception of Data Packets Between Compuer 
Networks", authored by Ashar Aziz and Geoffrey Mulli- 
gan, assigned to the assigned of the present invention 
and herein Incorporated by referenced in the entirety. 
10 As prevbusiy discussed, a second portion of the 
present invention includes key request process 126 
(FIG. 1). Accordingly, a requesting nodes uses key re- 
quest process 1 26 to request the multicast cryptograph- 
ic key, such as a group Interchange key or GIK, from the 
IS one or more seed nodes and the one or more keyed 
nodes coupled to the Internetwork. As will be apparent 
from the discussk)n below, a requesting node using key 
request process 1 26 will obtain a multicast cryptograph- 
ic key from the keyed node or seed node closest to the 

20 requesting node at the time of the request. Compared 
with other nodes on the network, the closest seed node 
or keyed node can send a packet to the requesting node 
which traverses the least number of networks and thus 
uses the fewest number of hops. 

25 Ref emng to FIG. 3, a flow chart outlines the overall 
steps used by one embodiment of the present inventk>n 
to obtain the multicast cryptographic key. Initially, at step 
302. the requesting node generates a multicast request 
for a multsast cryptographic key. The multicast request 

30 Is transmitted over the internetwork and addressed to a 
special multsast address the seed nodes and keyed 
nodes are monitoring. It is important to note that the mul- 
ticast request can be both unencrypted and unaulhen- 
tlcated without compromising overall security of the mul- 

3S ticast key distribution process. Essentially, the seed 
nodes and keyed nodes receiving the request need only 
verify the requesting node Is an authorized node based 
on the authorized control lists (ACL) because the re- 
sponse Is encrypted In a manner only the real requesting 

^0 node will be able to decrypt. An imposter node attempt- 
ing "a man In the mkJdle" or other similar cryptographs 
attacks can act as an authorized requesting node but 
can not decrypt the response which has been encrypted 
using a secure unicast transmission such as SKIP This 

4S unique aspect of the present invention reduces the com- 
plexity associated with key management without com- 
promising the level of security. 

Next, at step 304, the requesting node transmits the 
multicast request a predetermined number of hops over 

50 the Internetwork to neart)y seed nodes and keyed nodes 
using an expanding multicast ring. The expanding mul- 
ticast ring can be viewed as a series of messages trans- 
mitted over the internetwork using an increasing hop 
count. Those skilled in the art will understand that a hop 

55 is defined as the distance between two networks cou- 
pled together by a router, a switch, a brkJge or other net- 
work connectivity devtee. Accordingly, each time a mes- 
sage travels between two networks, the networi^ con- 
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nectivity device decrements the hop count. Thus, the 
hop count measures how many networks away from the 
requesting node a message has travelled. Over time, 
the expanding multicast ring will send requests further 
out over the network looking for a seed nor or keyed s 
node which has the multicast cryptographic key. The ex- 
panding multicast ring locates the closest seed nor or 
keyed node rather than requesting a key from a centrally 
located node which may be geographically distant. As 
will become apparent from the following steps, the ex- 10 
panding multicast ring distributes the k>ad associated 
with the key-management process. 

At step 306, the requesting node waits a predeter- 
mined time period for at least one response from either 
a seed node or a keyed node. Next, determinatfon step »5 
308 determines if at least one response has been pro- 
vided within the predetemilned time period. If no re- 
sponse has been received, the expanding multicast ring 
was not large enough to locate a seed node or keyed 
node. Thus, processing transfers to step 31 0 where the 20 
hop count is increased a predetemnined hop count In- 
crement suitable under the circumstances. The appli- 
cant contemplates that various well known mathemati- 
cal number sequences such as cardinal, prime, fibon- 
acci and other mathematical relations could be used for 2S 
this predetermined hop count increment. For example, 
the hop count sequence used In one expanding multi- 
cast ring could be an exponential sequence such as 1 , 
2, 4, 8, 16, ... n2 . This hop count sequence woukJ ex- 
pand the multicastring quickly and therefore locate the oo 
multicast cryptographic key quickly. 

After increasing the hop count an appropriate 
number of times and performing steps 304-31 0 iterative- 
ly, the requesting node eventually receives a secure uni- 
cast transmlsston, including the multicast cryptographic 35 
key, from either a seed node or a keyed node coupled 
to the internetworic. if unicast SKIP is used, the multicast 
cryptographic key is encrypted using the two step en- 
cryption process discussed above. Accordingly, 
processing transfers from step 308 to step 312 where 40 
the destination node proceeds to decrypt the secure uni- 
cast transmissk>n to obtain the multk^ast cryptographic 
key value. 

At step 314 in FIG. 3 the receiving node determines 
if the multicast cryptographic key is authenticate or has 4S 
been falsified by an Imposter. Authentication can be 
done using several different techniques. One technique 
authentwates that the multicast cryptographic key is 
from a member of the multicast group using an access 
control list or ACL. This ACL is typically authenticated «> 
and distributed some time before the multk:ast transmis- 
sion and contains all the members In the multbast group 
and, if they exist, includes any seed members and keyed 
members. Another authentication technique relies on 
the secure unteast response containing the multicast 55 
cryptographic key encrypted using public key encryption 
techniques such as the one described in unicast SKIP 
Another technique authenticates the multicast crypto- 



graphic key by a digital signature on the multicast cryp- 
tographic key This digital signature may be time- 
stamped In order to prevent old digitally signed group 
keys from being re-used by an imposter seed node. 
Those skilled In the art will understand how a multicast 
cryptographic key is signed and authenticated In the 
manner discussed above. 

After authenticating the multicast cryptographic 
key, processing transfers to step 31 6 which converts the 
requesting node into a keyed node capable of distribut- 
ing the multicast cryptographs key using similar tech- 
niques discussed above for the seed nodes. This ena- 
bles the requesting node to distribute the cryptographic 
key to subsequent requesting nodes on the intemetwori< 
which are members of the multicast group and need the 
multicast cryptographic key. Thus, the seed node and 
the keyed nodes are functionally equivalent with respect 
to key distribution execpt that the seed node receives 
the multicast cryptographic key upon multicast group 
creation and the keyed node receives the multicast cryp- 
tographic key only after requesting and successfully re- 
ceiving the multicast cryptographic key Both the keyed 
node and the seed node are able to distribute the mul- 
ticast cryptographic key over the internetwork. In one 
embodiment, the requesting node converts itself into a 
keyed node by invoking a process whk:h allows the re- 
questing node to distribute the multicast cryptographic 
key in the same manner as the seed nodes discussed 
above. In an alternative embodiment, a seed node can 
convert a requesting node into a keyed node capable of 
distributing the multicast cryptographic key In this alter- 
native embodiment, the seed node transfers key distri- 
bution software onto the requesting node and config- 
ures key distribution software to perform the same key 
distribution techniques performed by the seed node for 
distributing the multicast cryptographic key. 

Embodiments of the invention offer several advan- 
tages in the area of key management for use in encryp- 
tion systems whtoh were previously unavailable in the 
art Unlike existing technques, this key management 
system scales well in a large multicasting network with 
members spread out over a large geographic distance. 
In the past, a single group coordinator (GC) would be- 
come quickly ovenvhelmed if all the members in a mul- 
ticast group requested an encryptton key in a short time 
Inten/al. For example, the multicast SKIP protocol used 
a single GC to distribute the multicast cryptographic key, 
called the group Interchange key (GIK), to each member 
of the multicast group who wanted to receive multicast 
transmissions. This worked well for small multicast 
groups but dki not scale well for larger multicast groups. 
By enhanching SKIP with teachings of the present In- 
vention, the processing associated with distributing the 
key is spread out to multiple seed nodes and keyed 
nodes on the internetwork. This technique minimizes 
the dennand on a central GC because members of the 
multicast group can request a GIK from the nearest 
keyed node or seed node rather than one centrally lo- 
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cated GC. The expanding ring of multicast requests fur- 
ther exploits the availability of cryptographic keys on 
multiple seed nodes and keyed nodes on a network by 
making requests for the multicast cryptographic key 
from the closest seed nodes and keyed nodes. 

The techniques used by the present invention are 
also beneficial because they balance the processing 
load associated with key distribution based on the geo- 
graphic locatton of key requests. Each additional cryp- 
tographic key request establishes a keyed node which 
can distribute the cryptographic key to other nearby 
nodes on the internetwork. Using multiple seed nodes 
and keyed nodes to distribute the multteast cryptograph- 
ic key distributes the processing load to many different 
nodes rather than one group controlloer or GC. 

Further, requesting a cryptographic key using an 
expanding ring locates nearby seed nodes or keyed 
nodes rather than a distant node on the network. This 
minimizes networic traffic and makes key distribution 
fast and efficient. Consequently, members in a large 
multicast group will experience consistent key distribu- 
tion perfornnance when requesting cryptographic keys 
even if they are located in different geographic locatbns. 

While specific embodiments have been described 
herein for purposes of illustratbn, various modifications 
may be made without departing from the spirit and 
scope of the Invention, Generally, embodiments of the 
present Invention provide a technique for dynamically 
balancing the load associated with distributing a group 
key Thus, those skilled in the art will understand that 
embodiments of the present invention are not limited to 
wori< secure unicast SKIP but can work with any number 
of secure unicast key distribution techniques. Those 
skilled in the art will also understand that the present 
Inventton can be implemented using a variety of different 
networking protocols and is not limited to computer sys- 
tems coupled to a networic using the TCPIP protocol. 
Alternative embodiments substantially similar to the pre- 
ferred embodiment could be implemented except that 
the networt^ protocol would be SNA, Appletalk, IPX, X. 
25, SU P, or PPP Those skilled in the art understand that 
computer systems running TCP/IP can also communi- 
cate with other computer systems running other diverse 
network protocols such as SNA (Systems Network Ar- 
chitecture), IPX, Appletalk, or X.25. For more informa- 
tion on integrating TCP/IP and SNA networks see Inte- 
grating TCP/IP Into SNA . Taylor. Wordware Publishers. 
1993. 

Accordingly, the invention is not limited to the above 
described embodiments, but instead is defined by the 
appended claims In light of their full scope of equiva- 
lents. 
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a cryptograph^ key, Initially located on the one or 
more seed nodes, to a requesting node wherein the 
one or more seed nodes, the one or more keyed 
nodes, and the requesting node are each coupled 
to one or nriore networks in an internetwork, the 
method comprising the steps of: 

receiving a multicast transmission request for 
the cryptographic key from the requesting 
node; 

encrypting the cryptographic key; and 
transferring the encrypted cryptographic key to 
the requesting node with a secure unicast 
transmission. 

The method of Claim 1 wherein the receiving step 
further comprises the steps of : 

determining if the requesting node making the 
multicast request has permission to receive the 
cryptographk; key by performing the foltowing 



A method executed on one or more seed nodes and 
one or more keyed nodes for securely distributing 



comparing the identity of the requesting node 
with an authenticated list of nodes having per- 
mission to receive the cryptographic key; and 
responding to the multicast request rf the com- 
paring step indicates the requesting node is a 
member of the list of nodes having permission 
to receive the cryptographic key 

The method of Claim 1 further comprising the step 
of converting the requesting node into a keyed node 
by configuring the requesting node to perform a 
method comprising the following steps of: 

receiving a multicast transmission request for 
the cryptograph^ key from a subsequent re- 
questing node; 

encrypting the cryptographic key; and 
transf emng the encrypted cryptographic key to 
the subsequent requesting node with a secure 
untoast transmission. 

The method of Claim 1 wherein the cryptographic 
key is requested by the requesting node to decrypt 
data being transmitted over a secure multicast 
transmission between members of a multicast 
group. 

The method of Claim 1 further including the step of 
including the one or more seed nodes, the one or 
more keyed nodes, and the requesting nodes as 
members of a multicast group. 

The method of Claim 5 further including the step of 
distributing the one or more seed nodes over the 
intemetworit to minimize the distance over the in- 
ternetwork between each member of the multicast 
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group on the internetwork and a seed node or a 
keyed node on the internetwork. 

7. The nriethod of Claim 1 wherein the multicast re- 
quest made by the requesting node to the seed 
node is neither authenticated nor encrypted. 

8. The method of Claim 1 wherein the secure unteast 
transmission is perfomied using unkast SKIP. 

9. A method executed on a requesting node coupled 
to a network on an internetwork for obtaining a cryp- 
tographic key from one or more seed nodes and one 
or more keyed nodes coupled to one more different 
networks on the internetwork, wherein each of the 
one or more seed nodes and the one or more keyed 
nodes are capable of transmitting the cryptographic 
key to the requesting node, the method comprising 
the steps of: 

generating a multicast request for the crypto- 
graphic key; 

transmitting the multicast request for the cryp- 
tographs key a predetermined number of hops 
over the internetwork directed to the one or 
more seed nodes and the one or more keyed 
nodes coupled to the Internetwork; 
waiting for at least one response from at least 
one seed node or keyed node coupled to the 
network; and 

when the at least one response is not received 
within a time period, increasing the hop count 
by a hop count increment and repeating the 
above steps of generating a multicast request, 
transmitting the multicast request, and delaying 
a time perkxi. 

10. The method of Claim 9 further including the step of 
iteratively performing the steps of generating a mul- 
tteast request, transmitting the multicast request, 
delaying a time period, and increasing the hop 
count until the at least one response is received 
within the time period. 

11. The method of Claim 10 wherein the hop count In- 
crement is increased exponentially with each Itera- 
tion. 

12. The method of Claim 9, further comprising, subse- 
quent to the step of increasing the hop count, the 
steps of: 

receiving the at least one response within the 
time period in the fonm of a secure unicast 
transmission from at least one seed node or 
keyed node which includes the cryptographic 
key; 

decrypting the secure unfcast transmisston to 
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obtain the cryptographic key; and 
converting the requesting node into a keyed 
node capable of providing the cryptographk: 
key to other requesting nodes located on the 
intemetworit. 

13. The method of Claim 9 wherein the cryptographic 
key is requested by the requesting node to decrypt 
data being transmitted over a secure multicast 
transmission between members of a multicast 
group. 

14. The method of Claim 9 wherein the multicast re- 
quest made by the requesting node to the one or 
more seed nodes and the one or more keyed nodes 
is neither authenticated nor encrypted. 

1 5. The method of Claim 1 2 wherein the secure unicast 
transmission is performed using unicast SKIP. 

1 6. An apparatus embedded in one or more seed nodes 
and one or more keyed nodes which securely dis- 
tributes a cryptographic key, initially located on the 
one or more seed nodes, to a requesting node 
wherein the one or more seed nodes, the one or 
more keyed nodes, and the requesting node are 
each coupled to one or more networks In an Inter- 
networi^, the apparatus comprising: 

a mechanism configured to receive a multkjast 
transmission request for the cryptographic key 
from the requesting node; 
a mechanism configured to encrypt the crypto- 
graphic key; and 

a mechanism configured to transfer the en- 
crypted cryptographic key to the requesting 
node with a secure unicast transmisston. 

17. The apparatus of Claim 1 6 wherein the mechanism 
configured to receive is further comprised of: 

a mechanism configured to determine if the re- 
questing node making the multicast request 
has permission to receive the cryptographic 
key by performing the following steps, 
a mechanism configured to compare the iden- 
tity of the requesting node with an authenticat- 
ed predetermined list of nodes having pemiis- 
sion to receive the cryptograph^ key; and 
a mechanism configured to respond to the mul- 
ticast request if the comparing mechanism in- 
dicates the requesting node is a member of the 
predetermined list of nodes having permission 
to receive the cryptographic key 

1 8. The apparatus of Claim 1 7, having a mechanism to 
convert the requesting node Into a keyed node ca- 
pable of distributing the cryptograph^ key to a sub- 
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sequent requesting node, further comprising: 

a mechanism configured to receive a multicast 
transmission request for the cryptographic key 
from a subsequent requesting node; s 
a mechanism configured to encrypt the crypto- 
graphic key; and 

a mechanism configured to transfer the en- 
crypted cryptographic key to the subsequent 
requesting node with a secure unk^ast trans- 10 
misston. 

19. The apparatus of Claim 16 wherein the crypto- 
graphic key is requested by the requesting node to 
decrypt data being transmitted over a secure multi- is 
cast transmission between members of a multk»st 
group. 

20. The apparatus of Claim 16 further including the step 

of including the one or more seed nodes, the one 20 
or more keyed nodes, and the requesting nodes as 
members of a multicast group. 

21. The apparatus of Claim 16 further including an ap- 
paratus configured to distribute the one or more ^ 
seed nodes over the internetwork to minimize the 
distance over the internetwork between each mem- 
ber of the multtoast group on the Internetwork and 

a seed node or a keyed node on the Internetwork. 

30 

22. The apparatus of Claim 1 6 wherein the multicast re- 
quest made from the requesting node to the seed 
node is neither authenticated nor encrypted. 

23. The apparatus of Claim 1 6 wherein the secure uni- 3S 
cast transmission Is perfomned using unicast SKIP. 

24. An apparatus embedded In a requesting node cou- 
pled to a network on an internetwork configured to 
obtain a cryptographic key from one or more seed 40 
nodes and one or more keyed nodes coupled to one 
more different networks on the intemetwork. where- 
in each of the one or more seed nodes and the one 

or more keyed nodes are capable of transmitting the 
cryptographic key to the requesting node, the ap- 4S 
paratus comprising: 

a mechanism configured to generate a multi- 
cast request for the cryptographic key; 
a mechanism configured to transmit the multi- so 
cast request for the cryptographic key a prede- 
termined number of hops over the Internetwork 
directed to the one or nrK)re seed nodes and the 
one or more keyed nodes coupled to the inter- 
network; 55 
a mechanism configured to delay a time period 
for at least one response from at least one seed 
node or keyed node coupled to the network; 



and 

a mechanism configured to Increase the hop 
count by a hop count Increment when the at 
least one response is not received within the 
time period. 

25. The apparatus of Claim 24 wherein the mechanism 
configured to Increase the hop count increases the 
hop count Increment exponentially each time it Is 
operated. 

26. The apparatus of Claim 24. further comprising: 

a mechanism configured to receive the at least 
one response, within the time period, in the 
form of a secure unicast transmission from at 
least one seed node or keyed node which in- 
cludes the cryptographic key; 
a mechanism configured to decrypt the secure 
unicast transmission to obtain the cryptograph- 
k; key; and 

a mechanism configured to convert the re- 
questing node into a keyed node capable of 
providing the cryptographic key to other re- 
questing nodes located on the internetwork. 

27. The apparatus of Claim 24 wherein the crypto- 
graphic key is requested by the requesting node to 
decrypt data being transmitted over a secure multi- 
cast transmissbn between members of a multicast 
group. 

28. The apparatus of Claim 24 wherein the multicast re- 
quest made by the requesting node to the one or 
more seed nodes and the one or more keyed nodes 
is neither authenticated nor encrypted. 

29. The apparatus of Claim 24 wherein the secure uni- 
cast transmisskm Is perfonned using unicast SKIP. 

30. A computer data signal embodied in a carrier wave 
and representing sequences of instructfons which, 
when executed by a processor, causes one or more 
seed nodes and one or more keyed nodes in to se- 
curely distribute a cryptographic key, initially locat- 
ed on the one or more seed nodes, to a requesting 
node wherein the one or more seed nodes, the one 
or more keyed nodes, and the requesting node are 
each coupled to one or more networks in an Inter- 
network, by performing the following steps of: 

receiving a multicast transmission request for 
the cryptographic key from the requesting 
node; 

encrypting the cryptographic key; and 
transfemng the encrypted cryptographic key to 
the requesting node with a secure unicast 
transmlssk)n. 
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31 . The data signal embodied In a carrier wave of Claim 
30 wherein the receiving step further comprises the 
steps of: 

determining if the requesting node malcing the 
multicast request has permission to receive the s 
cryptographic Icey by performing the following 
steps, 



comparing the Identity of the requesting node 
with an authenticated list of nodes having per- io 
mission to receive the cryptographic key; and 
responding to the multicast request if the com- 
paring step indicates the requesting node is a 
member of the list of nodes having permission 
to receive the cryptographic key. is 

32. The data signal embodied in a carrier wave of Claim 
30 further comprising the step of converting the re- 
questing node into a keyed node by configuring the 
requesting node to perform a method comprising 
the following steps of: 

receiving a multicast transmission request for 
the cryptographic key from a subsequent re- 
questing node; 2S 
encrypting the cryptographic key; and 
transferring the encrypted cryptographic key to 
the subsequent requesting node with a secure 
unicast transmission. 

30 

33. The data signal embodied In a carrier wave of Claim 
30 wherein the cryptographic key is requested by 
the requesting node to decrypt data being transmit- 
ted over a secure multicast transmission between 
members of a multicast group. 35 



34. The data signal embodied in a carrier wave of Claim 
30 further Including the step of including the one or 
more seed nodes, the one or more keyed nodes, 
and the requesting nodes as members of a multi- 
cast group. 



35. The data signal embodied in a carrier wave of Claim 
34 further including the step of distributing the one 
or more seed nodes over the Internetwork to mini- 
mize the distance over the internetwork between 
each member of the multicast group on the internet- 
work and a seed node or a keyed node on the in- 
ternetwork. 

36. The data signal embodied in a carrier wave of Claim 
30 wherein the multicast request made by the re- 
questing node to the seed node Is neither authenti- 
cated nor encrypted. 

37. The data signal embodied in a carrier wave of Claim 
30 wherein the secure unicast transmission is per- 
formed using unicast SKIP. 
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38. A computer data signal embodied in a carrier wave 
and representing sequences of Instructions which, 
when executed by a processor, causes a requesting 
node coupled to a network on an internetwork to ob- 
tain a cryptographic key from one or more seed 
nodes and one or more keyed nodes coupled to one 
more different networks on the internetwork, where- 
in each of the one or more seed nodes and the one 
or more keyed nodes are capable of transmitting the 
cryptographic key to the requesting node, by per- 
fomiing the following steps of: 

generating a multicast request for the crypto- 
graphic key; 

transmitting the multicast request for the cryp- 
tographic key a predetermined number of hops 
over the internetwork directed to the one or 
more seed nodes and the one or more keyed 
nodes coupled to the internetwork; 
waiting for at least one response from at least 
one seed node or keyed node coupled to the 
network; and 

when the at least one response is not received 
within a time period, increasing the hop count 
by a hop count increment and repeating the 
above steps of generating a multfcast request, 
transmitting the multteast request, and delaying 
a time period. 

39. The method of Claim 38 further Including the step 
of Iteratively performing the steps of generating a 
multicast request, transmitting the multicast re- 
quest, delaying a time period, and increasing the 
hop count until the at least one response is received 
within the time period. 

40. The computer data signal embodied in a carrier 
wave of Claim 39 wherein the hop count increment 
is Increased exponentially with each Iteratbn. 

41. The computer data signal embodied in a carrier 
wave of Claim 38, further comprising, subsequent 
to the step of increasing the hop count, the steps of: 

receiving the at least one response within the 
time period in the form of a secure unicast 
transmisston from at least one seed node or 
keyed node which includes the cryptographic 
key; 

decrypting the secure unicast transmission to 
obtain the cryptographic key; and 
converting the requesting node into a keyed 
node capable of providing the cryptographic 
key to other requesting nodes located on the 
internetwork. 

42. The computer data signal embodied in a carrier 
wave of Claim 38 wherein the cryptographic key is 
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requested by the requesting node to decrypt data 
being transmitted over a secure multicast transmis- 
sion between members of a multicast group. 

43. Tlie computer data signal embodied in a carrier s 
wave of Claim 38 wherein the multicast request 
made by the requesting node to the one or more 
seed nodes and the one or more keyed nodes is 
neither authenticated nor encrypted. 



44. The computer data signal embodied In a carrier 
wave of Claim 41 wherein the secure unicast trans- 
mission is performed using unicast SKIP. 
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